-
-
Notifications
You must be signed in to change notification settings - Fork 346
improvements to parse_dtype
#3264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…more JSON-like inputs, and test for round-trips
…into widen-parse-data-type
cc @TomNicholas |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3264 +/- ##
==========================================
+ Coverage 59.56% 59.65% +0.08%
==========================================
Files 78 78
Lines 8684 8690 +6
==========================================
+ Hits 5173 5184 +11
+ Misses 3511 3506 -5
🚀 New features to boost your workflow:
|
d684ada adds a test to ensure that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice - I like the name change. Having two identical functions in our API seems a bit confusing from a user POV: https://zarr--3264.org.readthedocs.build/en/3264/api/zarr/dtype/index.html#functions. Could you remove parse_data_type
from __all__
so it's removed from the docs, but will still be imported and work for backwards compatibility?
Co-authored-by: David Stansby <dstansby@gmail.com>
…into widen-parse-data-type
a notable recent change: I widened the accepted inputs even further, and now |
directly, or a JSON representation of a ZDType, or a native dtype, or a python object that | ||
can be converted into a native dtype. | ||
zarr_format : ZarrFormat | ||
The Zarr format version. This parameter is required because this function will attempt to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A stretch goal (for another issue/PR) - would it be possible to make this optional for certain inputs (e.g., converting 'int32' doesn't depend on the version of the zarr spec)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather not have a function where one parameter is optional depending on the value of another parameter. That should probably be a different function entirely, e.g. one that specifically takes numpy dtype-like inputs and finds the corresponding zarr data type.
Co-authored-by: David Stansby <dstansby@gmail.com>
Co-authored-by: David Stansby <dstansby@gmail.com>
Co-authored-by: David Stansby <dstansby@gmail.com>
Co-authored-by: David Stansby <dstansby@gmail.com>
Co-authored-by: David Stansby <dstansby@gmail.com>
Co-authored-by: David Stansby <dstansby@gmail.com>
parse_dtype
.parse_data_type
is kept around but it just wrapsparse_dtype
. The reason for this change is naming consistency -- theZDType
methods already use the "dtype" abbreviation extensively, so it's potentially confusing thatparse_data_type
does not.parse_dtype
(with the exception of "|O", which is ambiguous).closes #3263